Qual é a diferença entre 'git pull' e 'git fetch'?

1
2
Próximo
Em termos mais simples, git pull faz um git fetch seguido por um git merge.
Você pode fazer um git fetch a qualquer momento para atualizar seus branches de rastreamento remoto em refs / remotes /  /.
Esta operação nunca muda nenhum de seus próprios branches locais sob refs / heads, e é seguro fazer sem mudar sua cópia de trabalho. Eu até ouvi falar de pessoas executando git fetch periodicamente em um cron job em segundo plano (embora eu não recomende fazer isso).
Um git pull é o que você faria para atualizar um branch local com sua versão remota, enquanto também atualiza seus outros branches de rastreamento remoto.
Da documentação do Git para git pull:
Em seu modo padrão, git pull é a abreviação de git fetch seguido por git merge FETCH_HEAD.
|
Quando você usa pull, o Git tenta fazer o trabalho automaticamente para você. É sensível ao contexto, então Git irá mesclar quaisquer commits extraídos no branch em que você está trabalhando no momento. Pull mescla automaticamente os commits sem permitir que você os revise primeiro. Se você não administrar de perto suas filiais, poderá se deparar com conflitos frequentes.
Quando você busca, o Git reúne quaisquer commits do branch de destino que não existam em seu branch atual e os armazena em seu repositório local. No entanto, ele não os mescla com seu branch atual. Isso é particularmente útil se você precisa manter seu repositório atualizado, mas está trabalhando em algo que pode falhar se você atualizar seus arquivos.
Para integrar os commits em seu branch master, você usa merge.
|
É importante contrastar a filosofia de design do git com a filosofia de uma ferramenta de controle de origem mais tradicional como o SVN.
O Subversion foi projetado e construído com um modelo cliente / servidor. Existe um único repositório que é o servidor, e vários clientes podem buscar o código do servidor, trabalhar nele e, em seguida, enviá-lo de volta ao servidor. A suposição é que o cliente sempre pode entrar em contato com o servidor quando precisa realizar uma operação.
Git foi projetado para suportar um modelo mais distribuído sem a necessidade de um repositório central (embora você certamente possa usar um, se desejar). Além disso, o git foi projetado para que o cliente e o "servidor" não precisem estar online ao mesmo tempo. O Git foi projetado para que as pessoas em um link não confiável pudessem até mesmo trocar códigos por e-mail. É possível trabalhar completamente desconectado e gravar um CD para trocar o código via git.
Para oferecer suporte a este modelo, git mantém um repositório local com seu código e também um repositório local adicional que espelha o estado do repositório remoto. Ao manter uma cópia do repositório remoto localmente, o git pode descobrir as mudanças necessárias mesmo quando o repositório remoto não estiver acessível. Mais tarde, quando você precisar enviar as alterações para outra pessoa, o git pode transferi-las como um conjunto de alterações de um ponto no tempo conhecido para o repositório remoto.
git fetch é o comando que diz "atualizar minha cópia local do repositório remoto".
git pull diz "traga as mudanças no repositório remoto para onde mantenho meu próprio código".
Normalmente git pull faz isso fazendo um git fetch para trazer a cópia local do repositório remoto atualizada, e então mesclando as mudanças em seu próprio repositório de código e possivelmente em sua cópia de trabalho.
A lição é ter em mente que geralmente há pelo menos três cópias de um projeto em sua estação de trabalho. Uma cópia é seu próprio repositório com seu próprio histórico de commits. A segunda cópia é sua cópia de trabalho onde você está editando e construindo. A terceira cópia é sua cópia local "em cache" de um repositório remoto.
|
Aqui está a imagem de Oliver Steele de como tudo se encaixa:
Se houver interesse suficiente, suponho que posso atualizar a imagem para adicionar git clone e git merge ...
|
Um caso de uso do git fetch é que o seguinte dirá a você quaisquer mudanças no branch remoto desde seu último pull ... então você pode verificar antes de fazer um pull real, o que pode alterar os arquivos em seu branch atual e cópia de trabalho.
git fetch
git diff ... origin
Veja: https://git-scm.com/docs/git-diff sobre a sintaxe de pontos duplos e triplos no comando diff
|
Custou-me um pouco entender qual era a diferença, mas essa é uma explicação simples. master em seu localhost é um branch.
Ao clonar um repositório, você busca todo o repositório para o seu host local. Isso significa que nesse momento você tem um ponteiro de origem / mestre para HEAD e um mestre apontando para o mesmo HEAD.
quando você começa a trabalhar e faz commits, avança o ponteiro master para HEAD + seus commits. Mas o ponteiro origem / mestre ainda está apontando para o que era quando você clonado.
Portanto, a diferença será:
Se você fizer um git fetch, ele apenas irá buscar todas as mudanças no repositório remoto (GitHub) e mover o ponteiro origin / master para HEAD. Enquanto isso, seu mestre de filial local continuará apontando para onde ele está.
Se você fizer um git pull, ele basicamente fará fetch (como explicado anteriormente) e mesclará quaisquer novas alterações em seuramo mestre e mova o ponteiro para HEAD.
|
Às vezes, uma representação visual ajuda.
|
Resumidamente
git fetch é semelhante a pull, mas não mescla. ou seja, ele busca atualizações remotas (refs e objetos), mas seu local permanece o mesmo (ou seja, origem / mestre é atualizado, mas o mestre permanece o mesmo).
git pull puxa de um remoto e mescla instantaneamente.
Mais
git clone clona um repo.
git rebase salva coisas de seu branch atual que não está no branch upstream para uma área temporária. Seu branch agora é o mesmo de antes de você iniciar suas alterações. Então, git pull -rebase baixará as alterações remotas, retrocederá seu branch local, reproduzirá suas alterações no topo de seu branch atual uma por uma até que você esteja atualizado.
Além disso, git branch -a mostrará exatamente o que está acontecendo com todos os seus branches - locais e remotos.
Esta postagem do blog foi útil:
A diferença entre git pull, git fetch e git clone (e git rebase) - Mike Pearce
e cobre git pull, git fetch, git clone e git rebase.
====
ATUALIZAR
Pensei em atualizar isso para mostrar como você realmente usaria isso na prática.
Atualize seu repositório local remotamente (mas não mescle):
git fetch
Depois de baixar as atualizações, vamos ver as diferenças:
git diff master origin / master
Se você estiver satisfeito com essas atualizações, mescle:
git pull
Notas:
Na etapa 2: Para obter mais informações sobre diferenças entre local e remoto, consulte: Como comparar um branch git local com seu branch remoto?
Na etapa 3: provavelmente é mais preciso (por exemplo, em um repo de mudança rápida) fazer uma origem de rebase do git aqui. Veja o comentário de @Justin Ohms em outra resposta.
Veja também: http://longair.net/blog/2009/04/16/git-fetch-and-merge/
|
git-pull - Buscar e fundir com outro repositório ou um branch local
SINOPSE
puxa ...
DESCRIÇÃO
Executa git-fetch com os parâmetros fornecidos e chama git-merge para mesclar o
cabeça (s) recuperada (s) na ramificação atual. Com --rebase, chama git-rebase
em vez de git-merge.
Observe que você pode usar. (diretório atual) como o  para puxar
do repositório local - isso é útil ao mesclar branches locais
no ramo atual.
Observe também que as opções destinadas ao próprio git-pull e ao git-merge subjacente
deve ser fornecido antes das opções destinadas ao git-fetch.
Você puxaria se quiser que as histórias fossem mescladas, você buscaria se apenas 'quisesse o código', já que alguma pessoa tem marcado alguns artigos por aqui.
|
Você pode buscar em um repositório remoto, ver as diferenças e, em seguida, extrair ou mesclar.
Este é um exemplo para um repositório remoto chamado origin e um branch chamado master rastreando a origem / master do branch remoto:
git checkout master
git fetch
git diff origin / master
git rebase origin master
|
A resposta curta e fácil é que git pull é simplesmente git fetch seguido por git merge.
É muito importante observar que o git pull irá mesclar automaticamente, quer você goste ou não. Isso pode, é claro, resultar em conflitos de mesclagem. Digamos que seu controle remoto seja de origem e seu branch seja mestre. Se você git diff origin / master antes de fazer o pull, você deve ter alguma idéia de possíveis conflitos de fusão e pode preparar seu branch local de acordo.
Além de puxar e empurrar, alguns fluxos de trabalho envolvem rebase git, como este, que parafraseei do artigo vinculado:
git pull origin master
git checkout foo-branch
git rebase master
git push origin foo-branch
Se você se encontrar em tal situação, pode ficar tentado a usar o git pull --rebase. A menos que você realmente saiba o que está fazendo, eu desaconselho isso. Este aviso é da página de manual do git-pull, versão 2.3.5:
Este é um modo de operação potencialmente perigoso. Reescreve
história, o que não augura nada de bom quando você publicou essa história
já. Não use esta opção a menos que você tenha lido git-rebase (1)
cuidadosamente.
|
OK, aqui estão algumas informações sobre git pull e git fetch, para que você possa entender as diferenças reais ... em poucas palavras simples, fetch obtém os dados mais recentes, mas não as alterações de código e não vai mexer com seu código de branch local atual , mas obtenha as alterações de código e mescle-o com seu branch local, continue lendo para obter mais detalhes sobre cada um:
git fetch
Ele irá baixar todas as referências e objetos e quaisquer novos ramos para o seu Repositório local ...
Obter branches e / ou tags (coletivamente, "refs") de um ou mais
outros repositórios, junto com os objetos necessários para completar seus
histórias. Ramos de rastreamento remoto são atualizados (veja a descrição
abaixo para saber como controlar esse comportamento).
Por padrão, qualquer tag que aponte para os históricos que estão sendo buscados é
também buscado; o efeito é buscar tags que apontam para ramos que
você está interessado. Este comportamento padrão pode ser alterado usando
as opções --tags ou --no-tags ou configurando
remote..tagOpt. Usando um refspec que busca tags explicitamente,
você pode buscar tags que não apontam para ramos de seu interesse
em também.
git fetch pode buscar deum único repositório nomeado ou URL, ou
de vários repositórios ao mesmo tempo, se for fornecido e houver um
Remotos. entrada no arquivo de configuração. (Veja git-config1).
Quando nenhum controle remoto é especificado, por padrão o controle remoto de origem será
usado, a menos que haja um ramal upstream configurado para o atual
ramo.
Os nomes das referências que são buscadas, junto com os nomes dos objetos
eles apontam para, são gravados em .git / FETCH_HEAD. Esta informação pode ser
usado por scripts ou outros comandos git, como git-pull.
git pull
Ele irá aplicar as mudanças de remoto para a filial atual no local ...
Incorpora mudanças de um repositório remoto no branch atual.
Em seu modo padrão, git pull é uma abreviação de git fetch seguido por
git merge FETCH_HEAD.
Mais precisamente, git pull executa git fetch com os parâmetros fornecidos e
chama git merge para mesclar os cabeçalhos de ramificação recuperados no atual
ramo. Com --rebase, ele executa git rebase em vez de git merge.
deve ser o nome de um repositório remoto conforme passado para
git-fetch1. pode nomear um ref remoto arbitrário (por exemplo,
o nome de uma tag) ou mesmo uma coleção de referências com correspondentes
ramos de rastreamento remoto (por exemplo, refs / heads /: refs / remotes / origin /),
mas geralmente é o nome de um branch no repositório remoto.
Os valores padrão para e são lidos do
configuração "remota" e "mesclada" para o ramo atual conforme definido por
git-branch --track.
Também crio o visual abaixo para mostrar como git fetch e git pull funcionam juntos ...
|
Esta representação gráfica interativa é muito útil para compreender o git: http://ndpsoftware.com/git-cheatsheet.html
git fetch apenas "baixa" as alterações do repositório remoto para o seu repositório local. git pull baixa as mudanças e as mescla em seu branch atual. "Em seu modo padrão, git pull é a abreviação de git fetch seguido por git merge FETCH_HEAD."
|
Bônus:
Ao falar de pull & fetch nas respostas acima, gostaria de compartilhar um truque interessante,
git pull --rebase
Este comando acima é o comando mais útil na minha vida git que economizou muito tempo.
Antes de enviar seus novos commits para o servidor, tente este comando e ele sincronizará automaticamente as últimas mudanças no servidor (com fetch + merge) e colocará seu commit no topo do git log. Não há necessidade de se preocupar com o pull / mesclagem manual.
Encontre detalhes em: http://gitolite.com/git-pull--rebase
|
Gosto de ter alguma representação visual da situação para compreender essas coisas. Talvez outros desenvolvedores gostariam de ver também, então aqui está minha adição. Não estou totalmente certo de que tudo está correto, então, por favor, comente se encontrar algum erro.
SISTEMA LOCAL
. ========================================================== ===
=================. ================= =================== ===============
REPOSITÓRIO REMOTO. REPOSITÓRIO REMOTO CÓPIA DE TRABALHO DO REPOSITÓRIO LOCAL
(ORIGEM). (CACHED)
por exemplo,      . espelho do
um repositório github. . repo remoto
Pode ser também       .
vários repo's.
.
.
FETCH * ------------------> *
Seu cache local do controle remoto é atualizado com a origem (ou vários
fontes externas, ou seja, a natureza distribuída do git)
.
PUXAR   *------------------------------------------------ --------> *
as alterações são mescladas diretamente em sua cópia local. quando os conflitos ocorrem,
você é solicitado para decisões.
.
COMPROMETA-SE. * <--------------- *
Quando vindo de, por exemplo, subversão, você pode pensar que um commit
irá atualizar a origem. No git, um commit é feito apenas para seu repositório local.
.
PUSH * <--------------------------------------- *
Sincroniza suas alterações de volta à origem.
Algumas das principais vantagens de ter um espelho buscado do controle remoto são:
Desempenho (percorra todos os commits e mensagens sem tentar espremê-los na rede)
Feedback sobre o estado do seu repo local (por exemplo, eu uso o SourceTree da Atlassian, que me dará uma lâmpada indicando se estou com commits à frente ou atrás em relação à origem. Essas informações podem ser atualizadas com um GIT FETCH).
|
Eu também lutei com isso. Na verdade, cheguei aqui com uma pesquisa no google exatamente a mesma pergunta. Ler todas essas respostas finalmente pintou uma imagem em minha cabeça e decidi tentar analisar o estado dos 2 repositórios e 1 sandbox e as ações realizadas ao longo do tempo enquanto assistia a versão deles. Então aqui está o que eu inventei. Por favor, me corrija se eu errar em algum lugar.
Os três repositórios com uma busca:
--------------------- ----------------------- ------ -----------------
- Repo remoto - - Repo remoto - - Repo remoto -
- - - é empurrado - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------------------------------
- Repo local - - Repo local - - Repo local -
- puxar - - - - buscar -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Sandbox local - - Sandbox local - - Sandbox local -
- Check-out - - novo trabalho realizado - - -
- @ R01 - - @ R01 + - - @ R01 + -
--------------------- ----------------------- ------ -----------------
Os três repos com um puxão
--------------------- ----------------------- ------ -----------------
- Repo remoto - - Repo remoto - - Repo remoto -
- - - é empurrado - - -
- @ R01 - - @ R02 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Repo local - - Repo local - - Repo local -
- puxar - - - - puxar -
- @ R01 - - @ R01 - - @ R02 -
--------------------- ----------------------- ------ -----------------
--------------------- ----------------------- ------ -----------------
- Sandbox local - - Sandbox local - - Sandbox local -
- Check-out - - novo trabalho realizado - - fundido com R02 -
- @ R01 - - @ R01 + - - @ R02 + -
--------------------- ----------------------- ------ -----------------
Isso me ajudou a entender por que uma busca é muito importante.
|
A diferença entre GIT Fetch e GIT Pull pode ser explicada com o seguinte cenário:
(Tendo em mente que as imagens falam mais alto que as palavras !, forneci uma representação pictórica)
Vamos dar um exemplo de que você está trabalhando em um projeto com os membros de sua equipe. Portanto, haverá um Branch principal do projeto e todos os contribuidores devem bifurcá-lo em seu próprio repositório local e, em seguida, trabalhar neste branch local para modificar / adicionar módulos e enviar de volta ao branch principal.
Então,
O estado inicial dos dois ramos quando você bifurcou o projeto principal em seu repositório local será assim- (A, B e C são módulos já concluídos do projeto)
Agora, você começou a trabalhar no novo módulo (suponha que D) e quando tiver concluído o módulo D, você deseja empurrá-lo para o ramo principal, mas enquanto isso o que acontece é que um de seus colegas de equipe desenvolveu um novo Módulo E, F e C. modificado
Portanto, agora o que aconteceu é que seu repositório local está atrasado em relação ao progresso original do projeto e, portanto, enviar suas alterações para o branch principal pode levar a conflitos e fazer com que seu Módulo D funcione mal.
Para evitar tais problemas e trabalhar em paralelo com o andamento original do projeto, existem duas maneiras:
1. Git Fetch- Isso fará o download de todas as alterações que foram feitas no projeto de origem / ramo principal que não estão presentes em seu ramo local. E irá aguardar o comando Git Merge para aplicar as mudanças que foram buscadas em seu Repositório ou branch.
Portanto, agora você pode monitorar cuidadosamente os arquivos antes de mesclá-los ao seu repositório. E você também pode modificar D se necessário devido ao C. Modificado
2. Git Pull- Isso atualizará seu branch local com o branch de origem / principal, ou seja, o que ele faz é uma combinação de Git Fetch e Git merge um após o outro.
Mas isso pode causar conflitos, por isso é recomendado usar Git Pull com uma cópia limpa.
|
Simplesmente dizemos:
git pull == git fetch + git merge
Se você executar git pull, não precisará mesclar os dados ao local. Se você executar git fetch, significa que deve executar git merge para obter o código mais recente para sua máquina local. Caso contrário, o código de máquina local não seria alterado sem mesclagem.
Portanto, no Git Gui, quando você faz uma busca, precisa mesclar os dados. O próprio Fetch não fará alterações no código local. Você pode verificar isso ao atualizar o código, buscando
uma vez, busque e veja; o código não mudará. Então você mescla ... Você verá o código alterado.
|
git fetch puxa o código do servidor remoto para seus branches de rastreamento em seu repositório local. Se o seu remoto for nomeado origin (o padrão), então essas ramificações estarão em origin /, por exemplo origin / master, origin / mybranch-123, etc. Estas não são suas ramificações atuais, são cópias locais dessas ramificações do servidor .
git pull faz um git fetch, mas também mescla o código do branch de rastreamento com o seu atualversão local desse ramo. Se você ainda não está pronto para essas mudanças, apenas git fetch primeiro.
|
git fetch irá recuperar branches remotos para que você possa fazer git diff ou git fundi-los com o branch atual. git pull executará fetch no brach remoto rastreado pelo branch atual e então mesclará o resultado. Você pode usar git fetch para ver se há alguma atualização no branch remoto sem a necessidade de mesclá-los com o seu branch local.
|
Git Fetch
Você baixa as alterações em sua filial local da origem por meio de busca. Fetch pergunta ao repositório remoto todos os commits que outros fizeram, mas você não tem no repositório local. Fetch baixa esses commits e os adiciona ao repositório local.
Git Merge
Você pode aplicar as alterações baixadas por meio de busca usando o comando merge. Merge pegará os commits recuperados de fetch e tentará adicioná-los ao seu branch local. O merge manterá o histórico de commits de suas mudanças locais para que quando você compartilhar seu branch com push, Git saberá como outros podem mesclar suas mudanças.
Git Pull
Buscar e mesclar são executados juntos com frequência suficiente para que um comando que combine os dois, pull, seja criado. O pull faz uma busca e depois uma mesclagem para adicionar os commits baixados ao seu branch local.
|
Em termos simples, se você estivesse prestes a entrar em um avião sem nenhuma conexão com a Internet ... antes de partir, você poderia simplesmente fazer git fetch origin . Ele iria buscar todas as alterações em seu computador, mas mantê-lo separado de seu desenvolvimento / espaço de trabalho local.
No avião, você pode fazer alterações em seu espaço de trabalho local e, em seguida, mesclá-lo com o que você buscou e resolver possíveis conflitos de mesclagem, tudo sem uma conexão à Internet. E, a menos que alguém tenha feito novas alterações no repositório remoto, assim que chegar ao destino, você faria git push origin  e pegaria seu café.
Deste incrível tutorial Atlassian:
O comando git fetch baixa commits, arquivos e referências de um
repositório remoto em seu repositório local.
Buscar é o que você faz quando quer ver o que todo mundo tem
tem trabalhado. É semelhante à atualização do SVN, pois permite que você veja
como a história central progrediu, mas não o força a
realmente mescle as mudanças em seu repositório. Git isolados
buscou conteúdo a partir de conteúdo local existente, tem absolutamente
nenhum efeito em seu trabalho de desenvolvimento local. O conteúdo buscado deve ser verificado explicitamente usando o comando git checkout. Isto faz
buscar uma maneira segura de revisar os commits antes de integrá-los com
seu repositório local.
Ao baixar o conteúdo de um repositório remoto, os comandos git pull e git fetch estão disponíveis para realizar a tarefa. Você pode considerar
git busca a versão 'segura' dos dois comandos. Vai baixar
o conteúdo remoto, mas não atualiza o estado de trabalho do seu repositório local,
deixando seu trabalho atual intacto. git pull é o mais agressivo
alternativa, ele irá baixar o conteúdo remoto para o local ativo
ramificar e executar imediatamente git merge para criar um commit de mesclagem
para o novo conteúdo remoto. Se você tiver alterações pendentes em andamento
isso causará conflitos e iniciará a resolução do conflito de mesclagem
fluxo.
Com git pull:
Você não consegue nenhum isolamento.
Não precisa ser explicitamente verificado. Porque ele implicitamente faz uma fusão git.
A etapa de fusão afetará seu desenvolvimento local e pode causar conflitos
Basicamente, NÃO é seguro. É agressivo.
Ao contrário do git fetch, em que afeta apenas seu .git / refs / remotes, o git pull afetará seus .git / refs / remotes e .git / refs / heads /
Hmmm ... então, se eu não estou atualizando a cópia de trabalho com git fetch, onde estou fazendo alterações? Onde o Git busca armazenar os novos commits?
Ótima pergunta. Ele o coloca em algum lugar isolado de sua cópia de trabalho. Mas novamente, onde? Vamos descobrir.
No diretório do seu projeto (ou seja, onde você executa os comandos git), faça:
ls. Isso mostrará os arquivos e diretórios. Nada legal, eu sei.
Agora faça ls -a. Isso mostrará arquivos de ponto, ou seja, arquivos que começam com. Você poderá então ver um diretório chamado: .git.
Faça cd .git. Isso obviamente mudará seu diretório.
Agora vem a parte divertida; fazer ls. Você verá uma lista de diretórios. Estamos procurando por árbitros. Faça referências de cd.
É interessante ver o que está dentro de todos os diretórios, mas vamos nos concentrar em dois deles. cabeças e controles remotos. Use cd para verificar dentro deles também.
Qualquer git fetch que você fizer irá atualizar os itens no diretório /.git/refs/remotes. Ele não atualizará nada no diretório /.git/refs/heads.
Qualquer git pull fará primeiro o git fetch, atualizará os itens no diretório /.git/refs/remotes, depois se mesclará com o seu local e mudará o head dentro do diretório /.git/refs/heads.
Uma boa resposta relacionada também pode ser encontrada em Onde o 'git fetch' se posiciona ?.
Além disso, procure por "Notação de barra" na postagem de convenções de nomenclatura de ramificação Git. Isso ajuda você a entender melhor como o Git coloca as coisas emdiretórios diferentes.
Para ver a diferença real
Apenas faça:
git fetch origin master
git checkout master
Se o mestre remoto foi atualizado, você receberá uma mensagem como esta:
Seu branch está atrás de 'origin / master' por 2 commits, e pode ser acelerado.
(use "git pull" para atualizar seu branch local)
Se você não fez o download e apenas fez o git checkout master, seu git local não saberia que existem 2 commits adicionados. E diria apenas:
Já em 'master'
Sua filial está atualizada com 'origem / mestre'.
Mas isso está desatualizado e incorreto. É porque o git lhe dará feedback baseado exclusivamente no que ele sabe. Ele está alheio a novos commits que ainda não foram retirados ...
Existe alguma maneira de ver as novas alterações feitas remotamente enquanto trabalhava na filial localmente?
Alguns IDEs (por exemplo, Xcode) são superinteligentes e usam o resultado de uma busca git e podem anotar as linhas de código que foram alteradas no branch remoto do seu branch de trabalho atual. Se essa linha foi alterada por alterações locais e ramificação remota, então essa linha será anotada em vermelho. Este não é um conflito de mesclagem. É um potencial conflito de fusão. É um headsup que você pode usar para resolver o conflito futuro de mesclagem antes de fazer git pull do branch remoto.
Dica divertida:
Se você buscou um branch remoto, por exemplo fez:
git fetch origin feature / 123
Então, isso iria para o diretório remoto. Ainda não está disponível em seu diretório local. No entanto, isso simplifica seu checkout para essa filial remota por DWIM (Faça o que quero dizer):
recurso de checkout git / 123
você não precisa mais fazer:
git checkout -b feature / 123 origin / feature / 123
Para mais informações, leia aqui
|
A única diferença entre git pull e git fetch é que:
git pull puxa de um branch remoto e o mescla.
git fetch busca apenas do branch remoto, mas não mescla
ou seja, git pull = git fetch + git merge ...
|
Git permite que commits mais antigos cronologicamente sejam aplicados após commits mais novos.
Por causa disso, o ato de transferir commits entre repositórios é dividido em duas etapas:
Copiar novos commits do branch remoto para copiar deste branch remoto dentro do repositório local.
(operação repo para repo) master @ remote >> remote / origin / master @ local
Integrando novos commits à filial local
(operação dentro do repo) remote / origin / master @ local >> master @ local
Existem duas maneiras de realizar a etapa 2. Você pode:
Bifurca o branch local após o último ancestral comum e adiciona novos commits paralelamente aos commits que são exclusivos do repositório local, finalizado pela fusão do commit, fechando o fork.
Insira novos commits após o último ancestral comum e reaplique os commits exclusivos para o repositório local.
Na terminologia git, a etapa 1 é git fetch, a etapa 2 é git merge ou git rebase
git pull é git fetch e git merge
|
Git obtém o branch da versão mais recente do remoto para o local usando dois comandos:
git fetch: o Git obterá a versão mais recente do remoto para o local, mas não se mesclará automaticamente.

git fetch origin master
git log -p master..origin / master
git merge origin / master
Os comandos acima significam que baixar a versão mais recente do branch principal da origem do branch master remoto para o master de origem. E então compara o branch master local e o branch master de origem. Finalmente, mescle.
git pull: o Git obterá a versão mais recente do remoto e se unirá ao local.

git pull origin master
O comando acima é equivalente a git fetch e git merge. Na prática, git fetch pode ser mais seguro porque antes da fusão podemos ver as mudanças e decidir se devemos fazer a fusão.
|
Qual é a diferença entre git pull e git fetch?
Para entender isso, primeiro você precisa entender que seu git local mantém não apenas seu repositório local, mas também uma cópia local do repositório remoto.
git fetch traz sua cópia local do repositório remoto atualizada. Por exemplo, se seu repositório remoto for GitHub - você pode querer buscar todas as alterações feitas no repositório remoto para sua cópia local do repositório remoto. Isso permitirá que você execute operações como comparar ou mesclar.
O git pull, por outro lado, trará as mudanças no repositório remoto para onde você mantém seu próprio código. Normalmente, git pull fará um git fetch primeiro para trazer a cópia local do repositório remoto atualizada e, em seguida, mesclará as alterações em seu próprio repositório de código e possivelmente em sua cópia de trabalho.
|
git pull == (git fetch + git merge)
git fetch não muda para branches locais.
Se você já tem um repositório local com um remoto configurado para o projeto desejado, você pode pegar todos os branches e tags para o remoto existente usando git fetch. ... Fetch não faz nenhuma mudança nos branches locais, então você precisará fundir um branch remoto com um branch local pareado para incorporar as novas mudanças de busca. do github
|
Uma representação gráfica simples para iniciantes,
aqui,
git pull
irá buscar o códigodo repositório e rebase com o seu local ... no git pull há a possibilidade de novos commits serem criados.
mas em ,
git fetch
irá buscar o código do repositório e precisamos rebase-o manualmente usando git rebase
Ex: vou buscar do servidor mestre e rebase no meu mestre local.
1) git pull (o rebase será feito automaticamente):
git pull origin master
aqui a origem é o seu repo master remoto é o seu ramo
2) git fetch (precisa rebase manualmente):
git fetch origin master
ele irá buscar as alterações do servidor da origem. e estará em seu local até que você faça o rebase por conta própria. precisamos corrigir os conflitos manualmente, verificando os códigos.
git rebase origin / master
isso irá realocar o código em local. antes disso, certifique-se de que você está no ramo certo.
|
Tentando ser claro e simples.
O comando git pull é na verdade um atalho para git fetch seguido pelo git merge ou o comando git rebase, dependendo da sua configuração. Você pode configurar seu repositório Git de forma que git pull seja uma busca seguida por um rebase.
|
Na verdade, o Git mantém uma cópia do seu próprio código e
o repositório remoto.
O comando git fetch atualiza sua cópia local, obtendo dados do repositório remoto. Precisamos disso porque outra pessoa pode ter feito algumas alterações no código e você deseja se manter atualizado.
O comando git pull traz as mudanças no repositório remoto para onde você guarda seu próprio código. Normalmente, git pull faz isso fazendo um ‘git fetch’ primeiro para trazer a cópia local do repositório remoto atualizada e, em seguida, mescla as alterações em seu próprio repositório de código e possivelmente em sua cópia de trabalho.
|
1
2
Próximo
Questão altamente ativa. Ganhe 10 reputação para responder a esta pergunta. O requisito de reputação ajuda a proteger essa pergunta contra spam e atividades sem resposta.
Não é a resposta que você está procurando? Navegue por outras questões com a tag git version-control git-pull git-fetch ou faça sua própria pergunta.